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Intellectual Property Rights 

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Electronic Signatures and 
Infrastructures (ESI). 

The present document is part 1 of a multi-part deliverable covering Registered Electronic Mail (REM), as identified 
below: 



Part 1: 


"Architecture"; 


Part 2: 


"Data requirements, Formats and Signatures for REM"; 


Part 3: 


"Information Security Policy Requirements for REM Management Domains" 


Part 4: 


"REM-MD Conformance Profiles"; 


Part 5: 


"REM-MD Interoperability Profiles"; 


Part 6: 


"Interoperability Profiles": 



Sub-part 1 : "REM-MD UPU PReM Interoperability Profile" ; 
Sub-part 2: "REM-MD BUSDOX Interoperability Profile"; 
Sub-part 3: "REM-MD SOAP Binding Profile". 



Introduction 

Business and administrative relationships among companies, public administrations and private citizens, are the more 
and more implemented electronically. Trust is becoming essential for their success and continued development of 
electronic services. It is therefore important that any entity using electronic services have suitable security controls and 
mechanisms in place to protect their transactions and to ensure trust and confidence with their partners. 

Electronic mail is a major tool for electronic business and administration. Additional security services are necessary for 
e-mail to be trusted. At the time of writing the present document, in some European Union Member States (Italy, 
Belgium, etc.) regulation(s) and application(s) are being developed, if not already in place, on mails transmitted by 
electronic means providing origin authentication and proof of delivery. A range of Registered E-Mail ("REM") services 
is already established and their number is set to grow significantly over the next few years. Without the definition of 
common standards there will be no consistency in the services provided, making it difficult for users to compare them. 
Under these circumstances, users might be prevented from easily changing to alternative providers, damaging free 
competition. Lack of standardization might also affect interoperability between REM based systems implemented based 
on different models. The present document is to ensure a consistent form of service across Europe, especially with 
regard to the form of evidence provided, in order to maximize interoperability even between e-mail domains governed 
by different policy rules. 
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In order to move towards the general recognition and readability of evidence provided by registered e-mail services, 
it is necessary to specify technical formats, as well as procedures and practices for handling REM, and the ways the 
electronic signatures are applied to it. In this respect, the electronic signature is an important security component 
to protect the information and to provide trust in electronic business. It is to be noted that a simple "electronic 
signature" would be insufficient to provide the required trust to an information exchange. Therefore the present 
document assumes the usage of at least an Advanced Electronic Signature, with the meaning of article 2(2) of EU 
Directive 1999/93/EC [i.l], issued with a Secure Signature Creation Device, with the meaning of article 2(6) of the 
same Directive. 

The scope of each part is summarised below. 

TS 102 640-1 (the present document) "Architecture" provides an overall view of the REM, addressing all aspects: 

• Logical model, namely: Components, Styles of Operation, Roles within a REM-MD, REM-MDs grouping in 
administrative domains named REM Policy Domains. 

• Interfaces between the involved entities. 

• Events of shipment, transmission, delivery or download of messages concerning the REM environment and 
Evidence types generated by REM-MDs against these events. 

• Layering model and trust building among REM Management Domains, within the same or a different REM 
Policy Domain, or to non REM Systems. 

TS 102 640-2 [1] provides: 

• Rules for building a REM-MD Envelope and, consequently, a REM Dispatch or a REM-MD Message. 

• Syntax and semantics of REM-MD Evidence to be produced by a REM Management Domain. 

• Rules on the signature to be applied within REM-MD Envelopes. 

• Specifications on TSL to be issued for mutual recognition of REM-MDs. 

TS 102 640-3 [i.6] specifies requirements on the Registered E-Mail Management Domain (REM-MD) Information 
Security Management System based on per ISO/IEC 27001 [i.9]. 

Provisions, additional to ISO/IEC 27001 [i.9] controls, are also specified that address: 

• REM-MD practices statement. 

• REM Interconnection Statement. 

• REM Sender/REM Recipient Authentication. 

• Electronic signature related issues relevant to the REM. 

• measures related to records retention and destruction. 

TS 102 640-4 [i.7] "REM-MD Conformance Profiles" specifies two levels of conformance requirements: 

• Basic Conformance Profile that indicates the minimum set of mandatory requirements that are to be met by 
any REM-MD that claims to be conformant with TS 102 640-1 (the present document), TS 102 640-2 [1] and 
TS 102 640-3 [i.6]; and 

• Advanced Conformance Profile that includes a set of voluntary additional requirements to the Basic 
Conformance Profile for enhanced security and advanced evidential services. 

TS 102 640-5 [i.8] "REM-MD Interoperability Profiles" addresses the followings aspects: 

• Defines a profile for interoperability among REM-MDs based on SMTP relay protocol. 

• Profiles the implementation of TS 102 640 based systems, addressing issues relating to authentication, 
authenticity and integrity of the information to achieve interoperability between such systems. 

• Covers all the options to profile REM-MD for both styles of operation: S&N and S&F. 
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TS 102 640-6-1 [i. 1 1] "REM-MD UPU PReM interoperability Profile" provides: 

• Requirements for achieving interoperability between the Registered Electronic Mail systems that are compliant 
with parts 1 (the present document) to 2 [1] of TS 102 640 and systems that are compliant with UPU S52-1 
UPU Postal Registered electronic Mail functional specification (PReM henceforth) 

• All the necessary mappings between the two specifications taking into account also the objective to maintain 
and preserve the positive features present in both the realities as pursued in the present document. 

TS 102 640-6-2 [i.12] "REM-MD BUSDOX Interoperability Profile" specifies: 

• Requirements for achieving interoperability between the Registered Electronic Mail systems compliant with 
TS 102 640 and systems that are compliant with "Business Document Exchange Network service metadata and 
transport" specification. 

• Define all the necessary mappings between the two specifications. 
TS 102 640-6-3 [i. 13] "REM-MD SOAP Binding Profile" provides: 

• Rules for building a REM-MD Envelope (and, consequently, a REM Dispatch or a REM-MD Message) as 
well defined XML Information Sets (Infoset). 

• Rules for secure transport of the above REM-MD XML Infosets using SOAP, combined with appropriate 
bricks of the Web Services stack (profiling of WS-Addressing and WS-Security). 
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1 Scope 

The basic purpose of Registered E-Mail service is to provide users, in addition to the usual services supplied by the 
ordinary e-mail service providers, with a set of Evidence suitable to uphold assertions of acceptance (i.e. of 
"shipment"), of delivery/non delivery, of retrieval, etc. of e-mails sent/delivered through such service. 

The present document specifies an architectural structure of REM, more specifically: 

a) describes a logical model for REM including the most relevant REM architectural elements and how they 
relate to each other (REM-MD Messages, REM Sender, REM Recipient, etc.) and the following styles of 
operation: 

1) "Store and Forward" (S&F henceforth), whereREM Objects are directly forwarded from REM-MDs to 
the REM Recipient; and 

2) "Store and Notify" (S&N henceforth) where the REM Recipient is first notified of that a REM Object is 
stored and is provided with a reference to the location where the REM Object can be downloaded. 

b) describes how REM components interact using external interfaces to REM users, and interfaces to other REM 
implementations ; 

c) describes a policy domain environment; and 

d) specifies a list of different types of events and the REM-MD Evidence types that represent them. 

Evidential services are deemed to comply with legal, regulatory or contractual requirements to provide legal validity 
and enforceability under domestic or international law. 

The present document does not provide specification for interactions among architectural elements internal to the 
REM-MD. Although interfaces to physical mail could exist, the present document does not provide standardized 
interfaces to physical mail. 

The structure of the present document is as follows: 

• clause 2 contains the list of normative and informative references; 

• clause 3 includes definitions of the relevant concepts to the present document and abbreviations; 

• clause 4 contains the logical model for REM provision; 

• clause 5 specifies REM interfaces; 

• clause 6 provides a list of different types of events and REM-MD Evidence; and 

• clause 7 deals with the implementation of a TSL based mechanism for allowing mutual trust of REM-MDs. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox. etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee 
their long term validity. 
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2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 102 640-2: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 2: Data requirements, Formats and Signatures for REM". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a 

Community framework for electronic signatures. 

[i.2] Void. 

[i.3] ETSI TS 102 023: "Electronic Signatures and Infrastructures (ESI); Policy requirements for time- 

stamping authorities". 

[i.4] IETF RFC 3161 (2001):"Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)". 

[i.5] IETF RFC 1305 (1992): "Network Time Protocol (Version 3) Specification, Implementation and 

Analysis". 

[i.6] ETSI TS 102 640-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 3: Information Security Policy Requirements for REM Management Domains". 

[i.7] ETSI TS 102 640-4: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 4: REM-MD Conformance Profiles". 

[i.8] ETSI TS 102 640-5: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 5: REM-MD Interoperability Profiles". 

[i.9] ISO/IEC 27001:2005: "Information technology - Security techniques - Information security 

management systems - Requirements". 

[i.10] ETSI TS 102 231: "Electronic Signatures and Infrastructures (ESI); Provision of harmonized 

Trust-service status information". 

[i.l 1] ETSI TS 102 640-6-1: "Electronic Signatures and Infrastructures (ESI); Registered Electronic 

Mail (REM); Part 6: Interoperability Profiles; Sub-part 1: REM-MD UPU PReM Interoperability 
Profile". 

[i. 12] ETSI TS 102 640-6-2: "Electronic Signatures and Infrastructures (ESI); Registered Electronic 

Mail (REM); Part 6: Interoperability Profiles; Sub-part 2: REM-MD BUSDOX Interoperability 
Profile". 

[i. 1 3] ETSI TS 102 640-6-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic 

Mail (REM); Part 6: Interoperability Profiles; Sub-part 3: REM-MD SOAP Binding Profile". 

[i.14] ETSI TS 101 733 (Vl.5.1): "Electronic Signatures and Infrastructures (ESI); CMS Advanced 

Electronic Signatures (CAdES)". 

[i.15] ETSI TS 101 903 (Vl.2.2): "Electronic Signatures and Infrastructures (ESI); XML Advanced 

Electronic Signatures (XAdES)". 
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3 Definitions and abbreviations 
3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

certification authority: authority trusted by one or more users to create and assign public -key certificates 

information security policy: statement of policy which provides management direction and support for information 
security in accordance with business requirements and relevant laws and regulations 

long term storage: role that supports the integrity of data and the authenticity of a signature over the period required to 
store data for evidential purposes that can be used by the Message Archive 

message archive: optional role that supports storage of REM Objects and REM-MD Evidence, as required for later use 
for evidential or any other legally admitted purposes, at the relevant REM-MD for an indefinite or definite time period, 
to be accessed once or many times by one or more entities 

original message: e-mail message generated by the Sender's User Agent or under the Sender's technical/legal 
responsibility (i.e. outside of the REM-MD), which may be signed by the Sender 

NOTE: It has to be conveyed to the REM Recipient either by value (in the Store & Forward Style of operations) 
or by reference (in the Store & Notify Style of operations). 

Registered E-Mail (REM): enhanced form of mail transmitted by electronic means (e-mail) which provides evidence 
relating to the handling of an e-mail including proof of submission and delivery 

REM dispatch: REM-MD Envelope containing the Original Message and related REM-MD Evidence 

REM Management Domain (REM-MD): set of technical and physical components, personnel, policies and processes 
that provide REM services 

NOTE: A REM-MD is operated under the responsibility of a single management entity. 

REM-MD envelope: signed structure generated by the REM MD which envelopes an Original message and/or 
REM-MD Evidence 

REM-MD evidence: signed data created within a REM-MD, which proves that a certain event has occurred at a certain 
time 

NOTE: It may be signed directly or indirectly by placing it within a REM-MD Envelope. 
REM-MD Evidence Provider: role that issues REM-MD Evidence 
REM-MD Evidence Verifier: role that supports the verification of REM-MD Evidence 

REM-MD Message: message generated by the REM MD under the REM MD sole technical/legal responsibility (i.e. 
inside of the REM MD) 

NOTE: It is to be signed by the entity legally responsible for the REM MD. It may be understood by the REM 
Recipient/REM Sender as a "receipt" or a "notification". A REM-MD Message carries an REM-MD 
Envelope containing REM-MD Evidence. 

REM-MD Message Gateway: role that supports the transfer of REM objects to conventional e-mail (e.g. Internet) 
services and physical postal delivery services 

REM Message Store: role that supports the storage of REM Objects. In other words the set of mailboxes of the users 

REM-MD Message Transfer Agent: role that supports the transfer of REM Objects to REM Recipient's and REM 
Sender's REM Message Store either directly or via the REM Object Relay Interface into another REM-MD or via a 
REM-MD Message Gateway 

REM-MD Repository: role that supports the storage of REM Objects, REM-MD Evidence and any other, which must 
be accessed by reference 
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REM-MD Repository Retrieval Interface: interface of REM-MD towards REM UA used in the Store and Notify 
Style of Operation by the REM Recipient for downloading REM Objects from REM-MD Repository 

NOTE: It can also be used by REM Senders for downloading REM-MD Evidence. 

REM-MD Sender Message Submission Interface: interface of REM-MD towards sender REM UA used by the REM 
Sender to submit Original Messages to his REM-MD, for them to be forwarded to the REM Recipients 

REM-MD Sender/Recipient Message Store Retrieval Interface: interface of REM-MD towards REM UA used by 
REM Senders or REM Recipients to fetch REM Objects addressed to them 

REM-MD Third Party Evidence Retrieval Interface: interface that supports REM-MD Evidence and REM Objects 
retrieval by users that are parties external to the usual message flow 

REM Object: message object handled by a REM-MD. This is a REM-MD Message, REM-Dispatch or Original 

message 

REM Objects Relay Interface: interface that supports REM objects relaying between disparate REM-MD 

REM Policy: set of rules (e.g. legal, company policy or agreement) enforced for the provision of REM Services 

REM Policy Domain: any domain where a common set of rules (e.g. legal, company policy or agreement) is enforced 
for the provision of REM services 

NOTE: This domain may be a country, a Company, a group of Countries, etc., even a single REM-MD. 

REM Policy Domain Authority: authority entitled to enforce the common set of rules in which the REM policy 
Domain consists 

REM Recipient: physical or legal entity legally responsible for the mailbox to which the original message is addressed 

REM Sender: physical or legal entity legally responsible for the mailbox from which the original message has been 
sent 

REM Third Party: party authorized to access REM Objects and REM-MD Evidence for specific purposes 

REM User Agent (REM-UA): entity by which REM Senders, REM Recipients participate in the exchange of REM 
Objects and Third Parties may access REM Objects 

Signature Creation Server: server that supports the creation of digital signature against data (e.g. evidence) 
Time-Stamping Authority: authority which issues time-stamp tokens (TS 102 023 [i.3]) 

Time-Stamp Token: data object that binds a representation of a datum to a particular time, thus establishing evidence 
that the datum existed before that time (TS 102 023 [i.3]) 

Throughout the present document a number of verbal forms are used, whose meaning is defined below. 

• Shall, shall not: indicate requirements strictly to be followed in order to conform to the present document and 
from which no deviation is permitted. 

• Should, should not: indicate that among several possibilities one is recommended as particularly suitable, 
without mentioning or excluding others, or that a certain course of action is preferred but not necessarily 
required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited. 

• May, need not: indicate a course of action permissible within the limits of the present document. 
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3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AdES Advanced Electronic Signature 

CA Certification Authority 

CAdES CMS Advanced Electronic Signatures 

CEN Comite Europeen de Normalization 

NOTE: CEN was founded in 1961 by the national standards bodies in the European Economic Community and 
EFTA countries, that are contributing to the objectives of the European Union and European Economic 
Area with voluntary technical standards. 



CMS 


Cryptographic Message Syntax 


CSP 


Certification Service Providers 


EUMS 


EU Member States 


MD-RI 


Message and Evidence Relay Interface 


NTP 


Network Time Protocol 


QC 


Qualified Certificate 


REM 


Registered E-Mail 


REM-MD 


REM Management Domain 


REM-PD 


REM Policy Domain 


RSRI 


REM-MD Repository Retrieval Interface 


REM-UA 


REM User Agent 


S&F 


Store and Forward 


S&N 


Store and Notify 


S/MIME 


Secure/Multipurpose Internet Mail Extensions 


S-MSI 


REM-MD Sender Message Submission Interface 


SMTP 


Simple Mail Transfer Protocol 


S/R-MSRI 


REM-MD Sender/Recipient Message Store Retrieval Interface 


TLS/SSL 


Transport Layer Security/Secure Sockets Layer 


TP-ERI 


REM-MD Third Party Evidence Retrieval Interface 


TrST 


Trust Service Token 


TSA 


Time Stamping Authority 


TSL 


Trust-service Status List 


TSP 


Trust Services Provider 


UPU 


Universal Postal Union 



NOTE: UPU is the primary forum for cooperation between postal-sector players and helps to ensure a truly 
universal network of up-to-date products and services. 

URL Uniform Resource Locator 

XAdES XML Advanced Electronic Signature 



4 REM Logical Model 

This clause specifies a logical model for REM. The model is aimed at supporting a range of REM implementations that 
may employ different styles of operation. 

The model identifies those aspects of the REM that affect external interfaces to REM users, and interfaces to other 
REM implementations that may employ different styles of operation. Hence, the model is at a high level of abstraction 
and concentrates on those aspects of REM systems affecting external interfaces. The logical model is not related to any 
particular implementation. 
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4.1 REM Functional Viewpoint 

The basic elements of the REM Logical Model from the functional viewpoint are illustrated in figure 1 . 





Interface Interfaces in the model' 

S-MSI Sender- Message Submrnission Interface 
S-MSRI Sendee- Message Store Retrieval 
Interface 

R-MSRI: Recipient- Message Store Retrieval 
Interface 

RSRI: Reference Store Retrieval Interface 

TP-ERI: Tnird Parly Evidence Retrieval 
Interface 

MD-RI: REM-MD Message and 
Evidence Relay Interface 



REM 
UA 


a. 


REM 
UA 


a. 


REM 
UA 






REM 

Management Domain 



Recipient 



S-MSl: Original Message 
S-MSRI: REM-MD Messages 
R-MSRI: REM Objects 



Data objects flows through Interfaces: 



RRI: Original Messages, REM-MD Evidences 



TP-ERI: REM Objects 
ORI: REM Objects 
SEM-RI: REM Objects 



NOTE 1 : Arrows indicate service user and provider relationship, their points do not necessarily represent the 

direction of the exchanged data flow. Circles indicate interfaces for exposing services. Dashed arrows 
describe use of services through the mentioned interfaces. They do not indicate information flows or 
direction. 

NOTE 2: REM-MD RSRI interface is a mean that may be used also by not-subscriber REM Recipients. 
Figure 1: REM Logical Model - Functional Viewpoint 

In addition to transport services as provided by existing mailing systems, REM systems provide evidence services 
related to the submission, transmission (where applicable) and delivery of the REM Object. In particular, evidence 
services including some or all of evidence types mentioned in clause 6 should be provided to users (be they humans or 
systems). 

The REM users are the REM Sender, the REM Recipient and any Third Party that could be, for instance, the user's 
organization, a judge in case of dispute, or a party nominated by the REM Sender or REM Recipient for receiving 
Evidence on their behalf. The same entity may act as both REM Sender and REM Recipient. 

The REM Sender shall authenticate to the relevant REM-Management Domains (REM-MDs), but the choice of the 
authentication mechanism is left to the specific REM-MD. The REM Sender has access to the REM-MD services 
through a User Agent. 
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Delivery may require the REM Recipient's explicit acceptance of the new REM Object, This acceptance shall require 
authentication to the relevant REM-MD, but the choice of the authentication mechanism is left to the specific 
REM-MD. 

REM implementation components are broken into REM User Agents (REM-UA) and REM-MDs. 

The present document envisages scenarios where two REM-MDs might interoperate together via standard interfaces to 
provide the REM Object exchange. This is generally the case when the REM Sender and the REM Recipient are not in 
the same domain and therefore use different REM-MD. In this situation, the REM Object will have to be relayed 
between disparate REM-MDs. 

REM-UA will be used by the REM Sender to send new REM Objects that will be forwarded with Evidence created by 
one relevant REM-MD, where applicable, as well as for retrieving Evidence generated by any REM-MD. The REM-UA 
interface to the REM-MD may be realized by two interfaces: one for sending REM Objects the other for receiving 
REM Objects. A REM UA may interface to more than one REM-MD. The form a User Agent can take is not further 
specified here. It could be an application installed on user's machine or, in some case, it could be provided as a service 
by the REM-MD itself (e.g. web mail). 

These components interact using the interfaces described in clause 5, namely, REM-MD Sender Message Submission 
Interface, REM-MD Sender/Recipient Message Store Retrieval Interfaces, REM-MD Repository Retrieval Interface, 
REM Object Relay Interface, Non REM Relay Interface, REM-MD Third Party Evidence Retrieval Interface and 
REM-MD Repository Retrieval Interface. 



Two types of REM styles of operation are described below: "Store and Forward" (S&F), and "Store and Notify" (S&N). 
They may interoperate in a different range of combinations, such as: 

a) S&F to S&F, as described in clause 4.2.1; 

b) S&N to S&F, where a reference to REM Object contained in a REM-MD Repository is relayed to the REM 
Recipient's REM-MD using a canonical S&F service; 

c) S&N to S&N: in this operational scenario any reference to REM Object contained in a REM-MD Repository 
sent to a S&N REM-MD is relayed using a S&F service and it is handled, at REM Recipient's REM-MD's side 
by a S&F sub -component; 

d) S&F to S&N, as described in figure 4. 



This clause describes the style of operation "Store and Forward" (S&F henceforth). Under this style of operation REM 
Objects are directly forwarded from REM-MDs to the REM Recipient, certain REM-MD Messages are directly 
forwarded from REM-MDs to the REM Sender of the Original Message, and certain REM-MD-Messages (see clause 6) 
are directly forwarded from REM-MDs to the REM Recipient of the Original Message. 

Figure 2 shows two REM-MDs working under S&F style of operation interacting. A subscriber of the first REM-MD 
sends (this subscriber acts as REM Sender) a REM Object to a subscriber of the second REM-MD (this subscriber acts 
as REM Recipient of the Original Message). The figure shows an example of how the different REM Objects would 
flow among the different actors (REM-MDs and subscribers). 



4.2 



REM Styles of Operation 



4.2.1 



REM Store and Forward Style of Operation 
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Figure 2: REM Store & Forward Logical Model - REM Sender and REM Recipient 
subscribers of different REM-MDs 



In figure 2: 

a) the REM Sender submits, through the REM-MD Sender Message Submission Interface, the Original Message 
addressed to the REM Recipient (flow 1 in figure 2); 

b) the REM Sender's REM-MD may generate REM-MD Evidence for the REM Recipient. It may then create 
and forward a REM Dispatch including the Original Message and the aforementioned REM-MD Evidence, to 
the Recipient's REM-MD, Alternatively it may create a REM-MD Message containing only the REM-MD 
Evidence and separately forward this REM-MD Message and the Original Message to the Recipient's 
REM-MD through the REM Object Relay Interface (flow 2 in figure 2). Should the Recipient not be 
subscribed to any REM-MD, the Sender's REM-MD would forward the REM Object to the standard e-mail 
management domain through the Non-REM Relay Interface (SEM-RI in figure 2) (flow 2A in figure 2); 

NOTE: Where a REM-MD Message is forwarded by one REM-MD to a non REM-MD it may contain no 
REM-MD Evidence. 



c) the REM Recipient's REM-MD receives any of the REM Objects aforementioned. It may generate new 
REM-MD Evidence. It may then deliver a REM Dispatch with the Original Message and any REM-MD 
Evidence generated so far, or separately forward the Original Message and REM-MD Messages with 
REM-MD Evidence, to the REM Recipient through the Recipient Message Store Retrieval Interface 
(flow 3 in figure 2); 

d) in addition to the former actions and flows, a REM Sender's REM-MD may also generate specific REM-MD 
Evidence addressed to the REM Sender and deliver a REM-MD Message containing these REM-MD 
Evidence, through the REM-MD Sender Message Store Retrieval Interface (flow 4 in figure 2); 
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e) upon delivery in the REM Recipient's mailbox, or in case of non-delivery, the REM Recipient's REM-MD 
generates the corresponding REM-MD Evidence and sends a REM-MD Message containing such REM-MD 
Evidence addressed to the REM Sender. This REM-MD Evidence informs the REM Sender that the Original 
Message has been delivered/non delivered to the REM Recipient's mailbox (flow 5 in figure 2). 

The present clause does not provide details on the sequence of events leading to the generation of REM-Evidence, nor 
establishes rules on when, how or by whom these REM-Evidence will be incorporated into a REM Object A sequence 
is detailed in annex A, although a different set of actions and flows may also be present in actual implementations. 

REM-Evidence and formats for REM Objects flowing from one REM-MD to another using different technology are 
fully specified in TS 102 640-2 [1]. 



4.2.2 REM Store and Notify Style of Operation 

This clause describes the style of operation "Store and Notify" (S&N henceforth). Under this style of operation an 
Original Message or a REM-MD Evidence is not directly forwarded to the REM Recipient. 

The REM Sender's REM-MD stores the Original Message in its REM-MD Repository and creates a REM-MD Message 
for the REM Recipient that includes reference to REM-MD Repository. This reference to REM-MD Repository is made 
of a generic text, informing the REM Recipient that a REM Object intended for him/her is stored in the REM Sender's 
REM-MD's storage, and of a reference to the location where such REM Object can be downloaded from. 

In this model, a REM-MD provides additional interfaces for REM Senders and/or REM Recipients to access Original 
Message and/or REM-MD Evidence. 

The use of Store and Notify for the case where the REM Sender REM-MD supports store and notify is shown in 
figure 3. 
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Figure 3: REM Store & Notify Logical Model - REM Sender's REM-MD 
creating the REM-MD Message 



The flow and process steps as illustrated in figure 3 for this case are as follows: 

a) the REM Sender submits the Original Message, addressed to the REM Recipient, through the REM-MD 
Sender Message Submission Interface (flow 1 in figure 3); 
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b) the REM Sender's REM-MD: 

1) stores the REM Object in the REM-MD Repository; 

2) creates a REM-MD Message that contains a reference to the REM Object within the REM-MD 
Repository; 

3) adds any appropriate REM-MD Evidence to the aforementioned REM-MD Message or stores the 
REM-MD Evidence in the REM-MD Repository; and 

4) forwards this REM-MD Message to the REM Recipient's REM-MD using the REM Object Relay 
Interface (flow 2 in figure 3). Should the Recipient not be subscribed to any REM-MD, the Sender's 
REM-MD would forward the REM-MD Message to the standard e-mail management domain through 
the Non-REM Relay Interface (SEM-RI in figure 3) (flow 2A in figure 3); 

NOTE 1 : This REM-MD Message could be forwarded to the REM Recipient via an ordinary e-mail provider, but in 
this case its delivery would be out of the REM control. 

c) the REM Recipient's REM-MD forwards the REM-MD Message to the REM Recipient using the REM-MD 
Recipient Message Store Retrieval Interface (flow 3 in figure 3); 

d) the REM Recipient downloads the REM Object (and the REM-MD Evidence if they are stored in the 
REM-MD Repository) from the REM Sender's REM-MD Repository through the REM-MD Repository 
Retrieval Interface, (flow 4 in figure 3). Should the Recipient be not subscribed to any REM-MD, still she 
would download the corresponding REM Object from the REM Sender's REM-MD Repository through the 
aforementioned interface (flow 4A in figure 3). 

The use of store and notify for the case where the REM Recipients domain supports store and notify is shown in 
figure 4. 
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Figure 4: REM Store & Notify Logical Model - Recipient's REM-MD creating the REM-MD Message 



In figure 4: 

a) the REM Sender submits the Original Message addressed to the REM Recipient through the REM-MD Sender 
Message Submission Interface (flow 1 in figure 4); 

b) the REM Sender's REM-MD forwards the REM Object to the REM Recipient's REM-MD through the REM 
Object Relay Interface (flow 2 in figure 4); 
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c) the REM Recipient's REM-MD: 

1) stores the REM Object; 

2) creates a REM-MD Message that contains a reference to the REM Object within the REM-MD 
Repository; 

3) adds any appropriate REM-MD Evidence to the aforementioned REM-MD Message or stores the 
REM-MD Evidence in the REM-MD Repository; and 

4) delivers this REM-MD Message to the REM Recipient, through REM-MD Recipient Message Store 
Retrieval Interface (flow 3 in figure 4); 

d) the REM Recipient downloads the REM Object (and the REM-MD Evidence if they are stored in the 
REM-MD Repository) from the REM Recipient's REM-MD storage through the REM-MD Repository 
Retrieval Interface (flow 4 in figure 4). 

NOTE 2: Depending on the implementation the REM Recipient may be also asked to accept/reject downloading 
the REM Object or the REM-MD Evidence stored in the REM-MD repository. 

Hybrid implementations of this model may pass only some REM Object and/or REM-MD Evidence by reference, the 
rest being carried "in-band". For example: the data text can be carried in a REM-MD Message while attachments are 
referenced via a URL. 

The data flow to the user is separated from the flow informing the REM Recipient of the presence of that data as 
illustrated above. 

Signatures will be applied as specified in TS 102 640-2 [1]. 



4.3 Roles within a REM MD 

As illustrated in figure 5, the logical model refines the REM-MD into separate roles. A role represents some externally 
visible aspect of the functionality provided within a REM-MD or related to it. An implementation component may 
carry out one or more roles in supporting REM Services, as described in this clause. In addition, the same role may be 
supported by several implementation components. 
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Figure 5: Roles within a REM-MD 
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The REM-MD shall include the following Core Roles: REM-MD Message Transfer Agent, REM Message Store, and 
REM-MD Evidence Provider. A REM Message Store is allocated to the REM Senders and REM Recipients and is 
securely accessible by REM Sender and REM Recipients respectively to retrieve REM Objects addressed to them. 

The REM-MD may also include components supporting the following optional roles as described in figure 5: Message 
Archive, REM-MD Repository, REM-MD Evidence Verifier, and REM-MD Message Gateway. 

A REM-MD Message Gateway supports the transfer of REM-MD Messages to and from external conventional e-mail 
(e.g. Internet) services to physical postal delivery services, as follows: 

a) Gateway to physical mail: Where Original Messages are required by the REM Sender to be printed and 
forwarded by surface mail, or where this option is explicitly covered in the agreements between one REM-MD 
and its users. Please refer to clause 6 for further details on REM-MD Evidence. No general protocol is 
specified. 

NOTE: Transfer of physical mail to a REM Recipient is outside the scope of the present document, since, when 
enacted, it is a mechanism purely internal to the specific REM-MD that may, therefore, implement it 
autonomously. 

b) Gateway to ordinary email: REM MDs supporting this role should be able to exchange REM Objects, 
including REM Messages, in electronic form with non-REM service provider. However, a REM MD may just 
create and send REM-MD Evidence to provide certain types of evidence, for example: acceptance of the sent 
REM Object by the relevant REM-MD or notification that a REM Object is available for download from a 
REM-MD. Similarly, their needs might be satisfied by being able to exhibit trusted REM-MD Evidence that a 
certain REM Object, someone sent them, was actually received through their REM-MD at a certain time. 
Please refer to clause 6 for further details on REM-MD Evidence. Clause 5 of TS 102 640-2 [1] covers in 
detail these topics. 

The REM-MD architecture shall include a Certification Authority supporting role. Additionally the following 
supporting roles may be used by the ones listed above in support of their functions as described in figure 5: Signature 
Creation Server, Time-Stamping Authority (TSA) and Long Term Storage. 

Were entities and REM users are not equipped, or willing, to issue themselves signatures (e.g. on the REM-MD 
Evidence or the forwarded Original Message), they may take advantage of external Signature Creation Servers. The 
specific entity shall forward the to-be-signed object to the Signature Creation Server. Being this service provision most 
likely governed by a bilateral contractual relationship, the format and timing of the REM-MD Evidence is left up to 
these contracts, therefore no general protocol is specified. 

Time Stamping Authority is an independent entity that issues Time Stamping Tokens of the submitted digests 
(protocols specified in RFC 3161 [i.4] may apply). Concerning reliable time provider, trusted time providers may be 
used by any entity issuing the above mentioned REM-MD Evidence (the NTP - RFC 1305 [i.5] - specifications may be 
used). 

Among these supporting roles the CA and TSA roles shall not be in sourced. These services are intended to provide an 
additional layer of trust that only an entity third is able to give. 

4.4 REM Administrative Viewpoint 

From a policy and administrative viewpoint a set of REM-MDs may be grouped in Policy Domains as described in 
figure 6. 
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Figure 6: Logical grouping of REM-MDs in a policy domain 



As defined in clause 3.1, a REM policy domain is any domain where a common set of rules (e.g. legal, company policy 
or agreement) is enforced for the provision of REM services. A REM Policy Domain may have an Authority 
supervising the application of the policy and, within one REM-PD, there may be one or more REM-MD that provide 
end users with the whole set of REM related services. 

A REM-MD may belong to more than one REM-PD, provided that it complies with the rules of all of them. For 
example, a REM-MD set up in one country by a multinational company could be compliant to the sets of rules of both 
the relevant country and the multinational company. 

REM-MDs that exchange REM-MD Envelopes (be they actually REM Dispatches or REM-MD Messages) trust each 
other by definition if they belong to the same REM-PD, especially if such REM-PD is governed by an Authority that 
ensures that all REM-MDs abide by common rules. The mechanism by which such REM-MDs abidance is made known 
to any interested entity depends on the single REM-PD rules, and may span from simple mechanisms to more complex 
ones, in fact, being all involved REM-MDs members of the same Domain, they accept such mechanism and are capable 
to cope with it. 

On the other hand, when two REM-MDs belong to different REM-PDs there is the need for each of them to know 
whether their counterpart is considered as compliant with the rules of the purported REM-PD. This need would be 
hampered if each REM-PD acts, in practice, as an isolated domain that makes no information on their REM-MDs 
available from outside its own borders. 

Without this information exchange the REM-MD Envelopes (REM Dispatches or REM-MD Messages) may still 
technically be transmitted, but their but their reliability cannot easily be judged lacking the endorsement provided by the 
formal recognition by the relevant Authorities. 

It is therefore recommended that: 

1) a REM-PD-internal mechanism to provide authorised entities with information on the REM-MDs governed by 
the Authority of the involved REM-PD, likely the same REM-PD these entities belong to; this mechanism 
may be freely chosen by each REM-PD if it is used only within the REM-PD at issue; access to the 
information may even be restrict to a limited number of entities, requiring their authentication; 

2) a cross-REM-PD mechanism to allow the information in the item above to be accessed from one REM-PD to 
another; this mechanism, differently from the previous one, shall allow all the REM-MDs, that are supposed to 
reliably exchange REM-MD Envelopes, to ascertain the status of their counterparts in the relative pertaining 
REM-PDs. 

While the present document gives no indication on the mechanism as in previous item 1, although it proposes the TSL 
as in TS 102 231 [i.10], it recommends adoption of the said TS 102 231 [i.10] at least as a mechanism as in item 2. 
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5 REM Interfaces 

REM components, as described in clause 4.1, interact using the following interfaces: 

1) REM-MD Sender Message Submission Interface: this interface is used by the user acting as a REM Sender to 
submit REM Objects to his REM-MD, for them to be forwarded to the REM Recipients. It is recommended 
that REM Object are submitted protected (e.g. by using SMTP with TLS/SSL). The user may authenticate 
using passwords if protected and only used with an authenticated server (e.g. using TLS/SSL). 

2) REM-MD Sender/Recipient Message Store Retrieval Interfaces: this interface is used by REM Senders or 
REM Recipients to fetch REM Objects trough a reference to REM-MD Repository addressed to them. It is 
recommended that REM Objects are retrieved protected (e.g. using pop3, or imap with TLS/SSL). The user 
may authenticate using passwords if protected and only used with an authenticated server (e.g. using 
TLS/SSL). 

3) REM-MD Repository Retrieval Interface: this interface is used in the Store and Notify Style of Operation by 
the REM Recipient for downloading REM Objects or REM-MD Evidence from a REM-MD Repository. It 
may also be used by REM Senders for downloading REM-MD Evidence. It is recommended that REM 
Objects or REM-MD Evidence are retrieved protected (e.g. using HTTP or FTP using a URL with TLS/SSL). 
The user may authenticate using passwords if protected and only used with an authenticated server (e.g. using 
TLS/SSL). 

4) REM Object Relay Interface: the Relay interface allows REM Object and related REM-MD Evidence to be 
relayed between disparate REM-MDs. It is recommended that REM Object are relayed between REM-MDs 
using a recognised standard protocol which authenticates the origin of the REM Object (e.g. S/MIME over 
SMTP). 

5) Non REM Relay Interface: this interface is provided to allow client-based REM Object retrieval and 
web-based REM Object retrieval. It is recommended that REM Object are relayed using a recognised standard 
protocol which authenticates the origin of the REM Object (e.g. S/MIME over SMTP). 

6) REM-MD Third Party Evidence Retrieval Interface: this interface is provided to allow REM-MD Evidence 
and REM Object retrieval by users that are parties external to the usual message flow. These users might 
require access to REM-MD Evidence in some specific cases (i.e. a tribunal in case of dispute, or a third party 
nominated by the REM Sender or REM Recipient for receiving REM-MD Evidence on their behalf). 

NOTE: The present document does not standardize this interface. 



6 REM Events and REM-MD Evidence 
6.1 Overview 

In this clause the REM Events represented by REM-MD Evidence types are listed, along with a brief description of 
what event each REM-MD Evidence has the Purpose to state. Issued REM-MD Evidence can serve more purposes by 
including information related to more Events. The REM-MD Evidence topic is extensively addressed in 
TS 102 640-2 [1], clause 5.1 that covers also the REM-MD Evidence general structure and the content of each 
REM-MD Evidence type, as described in table 1 . 
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Table 1 : Event types and content of REM-MD Evidence 
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6.2.3 Event E.3 - Rejection of download by REM Recipient 
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6.2.4 Event H.1 - Successful forwarding for Ordinary e-mail 
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A REM Object may be electronically signed by the REM Sender to provide the REM Recipient with information on the 
REM Object origin and authenticity. Similarly, each REM-MD Evidence may be signed. At least the REM Object 
AND/OR all of the REM-MD Evidence it carries shall be signed. The REM Recipient may deem this information as 
reliable if the certificate supporting the signature is issued by a Certification Authority that the REM Recipient 
acknowledges as trusted (see note) and, where required, if the signature is issued by means of a Secure Signature 
Creation Device with the meaning of article 2(6) of the Directive 1999/93/EC [i.l]. Other signature attributes cannot be 
automatically inferred as reliable, for example the signing time that derives from the REM Sender's system that is not 
per se a trusted entity. 

NOTE: As an example, in the European Union, Certification Authorities issuing Qualified Certificates, as defined 
in the European Directive 1999/93/EC [i.l], article 2(10), are trusted since article 3(3) of the same 
Directive mandates that they are supervised in the EUMS they reside in. 

It is assumed that the signature is at least an Advanced Electronic Signature (AdES) as defined in Directive 
1999/93/EC [i.l] of the European Parliament and of the Council of 13 December 1999 on a Community framework for 
electronic signatures. Depending on the applicable legislation, this AdES may be supported with a QC and/or issued 
with a SSCD and, where required, if the signature is issued by means of a Secure Signature Creation Device. 

6.2 Event Types and their Proof 

In this clause the Events related to the basic REM functions are listed, logically grouped on the basis of what the related 
REM-MD Evidence types have the purpose to prove. 

In order to facilitate interoperability and based on the outcomes of a survey performed among a large number of 
interviewees, the REM-MD Evidence type related to each event below is indicated as "M" (mandatory), 
"R" (recommended) or "O" (optional). 
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6.2.1 Events and REM-MD Evidence related to the REM Sender's 
REM-MD 

A) Submission 

1) Submission acceptance 

Purpose of the related REM-MD Evidence: to prove that a certain REM Object was successfully 
submitted, at the time indicated in the REM-MD Evidence, to the REM Sender's REM-MD by the REM 
Sender upon authentication by the REM Sender's REM-MD. 

REM-MD Evidence Optionality: "M". 

2) Submission non acceptance 

Purpose of the related REM-MD Evidence: to prove that a certain REM Object that was submitted, at the 
time indicated in the REM-MD Evidence, to the REM Sender's REM-MD by the REM Sender upon 
authentication by the REM-MD, was not accepted by the REM Sender's REM-MD. 

REM-MD Evidence Optionality: "M". 



6.2.2 Events and REM-MD Evidence related to the REM Recipient's 
REM-MD 

B) Reception by the REM Recipient's REM-MD 

1) REM Object acceptance by the REM Recipient's REM-MD 

Purpose of the related REM-MD Evidence: to prove that one REM Object sent by the REM Sender's 
REM-MD and successfully received by the REM Recipient's REM-MD, was accepted by the latter. 

REM-MD Evidence Optionality: "R". 

2) REM Object rejection by the REM Recipient's REM-MD 

Purpose of the related REM-MD Evidence: to prove that one REM Object sent by the REM Sender's 
REM-MD and successfully received by the REM Recipient's REM-MD, was rejected by the latter due to 
policy, formal or technical reasons. 

REM-MD Evidence Optionality: "O". 

3) Non delivery within a given time period of the REM Object to the REM Recipient's REM-MD 

Purpose of the related REM-MD Evidence: to prove that it was impossible to deliver within a given time 
period a REM Object to the REM Recipient's REM-MD due to technical errors and/or other problems. 

NOTE: This may depend on: 

a) it is impossible for the REM Sender's REM-MD to identify the REM Recipient's REM-MD; 

b) the REM Recipient's REM-MD is unreachable; 

c) the REM Recipient's REM-MD rejected the REM Object for any reason. 
REM-MD Evidence Optionality: "R". 



6.2.3 Events and REM-MD Evidence related to the REM Recipient 

C) REM Object delivery 
1) Delivery 

Purpose of the related REM-MD Evidence: to prove that the REM Object was delivered to the REM 
Recipient's mailbox at a specific time. 
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REM-MD Evidence Optionality: "M". 
2) Non delivery within a given retention period 

Purpose of the related REM-MD Evidence: this REM-MD Evidence type has two purposes: 

a) to prove that the REM Object could not be delivered to the REM Recipient's mailbox within a 
given time period due to technical errors and/or other reasons; 

b) to indicate that no prove of delivery within a given period exists. 

The time limit is fixed by statutory or contractual rules, or it is pre-defined by the REM Sender. 
NOTE 1: The REM-MD Evidence applies to the following two different events: 

i) the REM Recipient's REM-MD sends back to the REM Sender's REM-MD the REM-MD Evidence 
of delivery/non delivery, to be forwarded to the REM Sender, in this case this REM-MD Evidence 
is generated by the REM Recipient's REM-MD; 

ii) the REM Sender's REM-MD, after having received from the REM Recipient's REM-MD the 
REM-MD Evidence that it accepted the REM Object to be delivered to the REM Recipient's 
mailbox, does not receive within a given time period from the same REM-MD the REM-MD 
Evidence as in item C.l; in this case the REM Sender's REM-MD will create this REM-MD 
Evidence with a suitable reason code to indicate the event type. 

REM-MD Evidence Optionality: "M". 

D) REM-MD Message delivery 

1) Delivery to the REM Recipient's mailbox of a reference to REM-MD Repository that a REM Object is 
available for downloading 

Purpose of the related REM-MD Evidence: to prove that the REM Recipient's REM-MD delivered to the 
REM Recipient's mailbox a reference to REM-MD Repository that a REM Object is ready to be 
downloaded from a REM-MD Repository. 

REM-MD Evidence Optionality: "M". 

2) Non delivery to the REM Recipient's mailbox within a given period of a REM-MD Message that a REM 
Object is stored and available to be downloaded 

Purpose of the related REM-MD Evidence: this REM-MD Evidence type has two purposes: 

a) to prove that the REM MD Message could not be delivered to the REM Recipient's mailbox within 
a given time period due to technical errors and/or other reasons; 

b) to indicate that no prove of delivery within a given period exists. 

The time limit is fixed by statutory or contractual rules, or it is pre-defined by the REM Sender. 
NOTE 2: The REM-MD Evidence applies to the following two different events: 

i) the REM Recipient's REM-MD sends back to the REM Sender's REM-MD the REM-MD Evidence 
of delivery/non delivery, to be forwarded to the REM Sender, in this case this REM-MD Evidence 
is generated by the REM Recipient's REM-MD; 

ii) the REM Sender's REM-MD, after having received from the REM Recipient's REM-MD the 
REM-MD Evidence that it accepted the REM-MD Message to be delivered, does not receive within 
a given time period from the same REM-MD the REM-MD Evidence as in item D.I.; in this case 
the REM Sender's REM-MD will create this REM-MD Evidence with a suitable reason code to 
indicate the event type. 

REM-MD Evidence Optionality: "M". 
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E) REM Object download 

1) Download 

Purpose of the related REM-MD Evidence: to prove that the REM Object was downloaded by the REM 
Recipient or by a delegate at a specific time. 

REM-MD Evidence Optionality: "M". 

2) Non download within a given retention period (see also item 14) 

Purpose of the related REM-MD Evidence: to prove that the REM Object was not downloaded within a 
given period from the REM-MD Repository under the responsibility of the REM Recipient's REM-MD 
due to technical errors and/or other reasons. 

The time limit is fixed by statutory or contractual rules, or it is pre-defined by the REM Sender. 
REM-MD Evidence Optionality: "M". 

3) Rejection by the REM Recipient of the REM Object to be downloaded 

Purpose of the related REM-MD Evidence: to prove that the REM Object to be downloaded was rejected 
by the REM Recipient. 

REM-MD Evidence Optionality: "R". 

4) Download by an entity delegated by the REM Recipient 

Purpose of the related REM-MD Evidence: to prove that the REM Object was downloaded by some 
entity delegated by the REM Recipient. 

REM-MD Evidence Optionality: "O". 

F) Content retrieval 

1) Retrieval 

Purpose of the related REM-MD Evidence: to prove that the REM Object present in the REM Recipient's 
mailbox was retrieved by the REM Recipient. 

NOTE 3: This REM-MD Evidence type is referred to the moment the REM Recipient actually accesses its mailbox 
with a mail client, be it an asynchronous client (like Outlook, Thunderbird, etc.) or a webmail client. 

REM-MD Evidence Optionality: "O". 

2) Non retrieval within a given period 

Purpose of the related REM-MD Evidence: to prove that the REM Object present in the REM Recipient's 
mailbox was not retrieved by the REM Recipient's mail client within a given period. 

REM-MD Evidence Optionality: "O". 

3) REM Object retrieval by an entity delegated by the REM Recipient 

Purpose of the related REM-MD Evidence: to prove that the REM Object was retrieved by some entity 
delegated by the REM Recipient. 

REM-MD Evidence Optionality: "O". 
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6.2.4 Events and REM-MD Evidence related to connections with outside 
the REM-MD 

G) Printing 

1) The Original Message was successfully submitted to a printing system to be subsequently sent via physical 
registered mail 

Purpose of the related REM-MD Evidence: to prove that a certain Original Message was, on behalf of 
the REM Sender's or REM Recipient's REM-MD, successfully printed to be forwarded via physical 
registered mail. 

NOTE 1: The Original Message may also be printed to be forwarded through physical registered mail on behalf of 
the REM Sender's or REM Recipient's REM-MD, in case the Original Message cannot be delivered into 
the REM Recipient's mailbox only if a specific statutory or contractual requirement exists to enact such 
forwarding. 

REM-MD Evidence Optionality: "O". 

2) The submission to a printing system of the Original Message to be subsequently sent via physical registered 
mail was unsuccessful 

Purpose of the related REM-MD Evidence: to prove that the REM Sender's or REM Recipient's 
REM-MD was unable to submit the Original Message to a printing system to subsequently forward it to 
physical registered mail. 

NOTE 2: See note in previous REM-MD Evidence. 

REM-MD Evidence Optionality: "O". 

H) Forward to regular e-mail 

1) The REM Object was successfully forwarded to a regular e-mail service 

Purpose of the related REM-MD Evidence: to prove that a certain REM Object was successfully 
forwarded on behalf of the REM Sender's or of the REM Recipient's REM-MD to a regular e-mail 
service. 



NOTE 3: Depending on the statutory or contractual agreements, the REM Sender's REM-MD or the REM 

Recipient's REM-MD may forward a REM Object to ordinary e-mail also if it is not able to forward it to 
the REM Recipient's REM-MD via REM. 

REM-MD Evidence Optionality: "O". 

2) The REM Object forwarding to regular e-mail was unsuccessful 

Purpose of the related REM-MD Evidence: to prove that the REM Sender's or REM Recipient's 
REM-MD was not able to forward a REM Object to a regular e-mail service. 

REM-MD Evidence Optionality: "O". 

I) Non REM origin 

1) E-mail message was successfully received from a regular e-mail system 

Purpose of the related REM-MD Evidence: to prove that a certain email was not received from a 
REM-MD but from an ordinary e-mail server, therefore all information related to its sending, like the 
REM Sender's address and the sending time, cannot be trusted per se. 
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7 REM Trust Building 

REM-MDs belonging to different REM-PDs may need to reliably implement a seamless mutual exchange of REM-MD 
Envelopes (be they actually REM Dispatches or REM-MD Messages). In this case, in addition to the interoperability 
related technicalities, it is indispensible, in order to achieve the desired reliability, that all the interested entities (i.e. 
Relying Parties) have access to the information on the abidance of the involved REM-MDs by the respective REM-PD 
rules. This access is required to be possible independently from what REM-PD the enquiring Relying Parties belong to. 
However, in a more restrictive implementation only a limited number of REM-PDs can agree to share this information 
type, thus not making it publicly open to anyone. 

Apart from the latest case, where the restricted number of entities (i.e. REM-PDs) can agree on a bespoke solution, it is 
advisable that the information exchange mechanism is as open as possible, so that, in subsequent times, Relying Parties 
belonging to additional REM-PDs can access the information at issue. 

The recommended common mechanism is the Trust-service Status List (TSL) specified in the TS 102 231 [i. 10] . 

NOTE: It is worth mentioning that TSL is being adopted in the European Union to share information on which 
Certification Service Providers - CSP - are reported as abiding by the regulation of the respective EU 
Member States - EUMS - on issuing ad managing Qualified Certificates. 

In the following clauses different implementation types are described, where each REM-PD Authority that governs one 
REM-PD assesses the compliance of the REM-MDs, belonging to the REM-PD it governs, with the rules established 
for that REM-PD. 

All the following implementation types do not intend to specify legal liabilities that are left to the applicable provisions. 

7.1 Closed REM-PD 

In one closed REM-PD, i.e. that envisages no interaction with other REM-PDs, any mechanism may be implemented to 
provide REM-PD wide accessibility to the REM-MD status information. 

Where the TSL is used to this purpose it would list the related REM-MD, specifying, as indicated in TS 102 231 [i.10], 
both their current status and, optionally, their status history. Any entity belonging to the same REM-PD would access 
the TSL and verify its authenticity as provided for by the REM-PD rules. In this TSL, the signing public key of each 
REM-MD, or preferably its corresponding certificates, would be published so that any relying party would be able to 
use it to verify their signature on each REM-MD Envelope they issue. Where applicable, the history of the REM-MDs' 
status (when it was initially approved, when, possibly, such approval was revoked and when was subsequently 
reinstated) could be also found in the TSL, allowing users to ascertain the reliability in the past of a specific REM-MD 
Envelope. The following provisions apply. 

a) The signature should be of the C/XAdES-T type as specified in TS 101 733 [i.14] and TS 101 903 [i.15]. No 
other extended signature forms are deemed necessary from the TSL verification standpoint. 

b) The TSL should be reissued at regular intervals to avoid the risk that two valid TSLs exist at the same time. A 
risk would in fact arise if users download one TSL soon after its issue time, then cache it and refer only to the 
cached copy up to the time specified in the "Next update" field (TS 102 231 [i.10], clause 5.3.15), without 
checking at every verification if a new TSL has been issued in the meantime. Should instead a new TSL be 
issued much ahead of the time specified in the "Next update" field, there would be two, or even more, non 
expired TSLs available, with negative consequences. Such overlap might instead be acceptable if it is just of 
few minutes. 

c) The TSL issue interval should not be longer than few months, depending on the volatility of the governed 
REM-MDs, to match the following requirements: 

1) timely updating the related REM-MDs status information; 

2) ensuring that the TSL signing certificate does not expire between two subsequent TSLs. The 
Authority's key pair and, where applicable, the related certificate should in fact be updated in 
advance of at least two TSL issuing intervals before the certificate expiration date. 
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d) The TSL signing public key should be made available to the interested entities through secure and reliable 
means, the choice of which is left up to the REM-PD governing Authority. One reliable means could for 
example be to publish its digest in an Official Journal. 

e) One REM-PD that has no interest to being interoperable with other REM-PDs may adopt other technical 
mechanisms form the TSL, but it should however enforce the above specified organisational provisions. 

7.2 Interoperable REM-PDs TSL - No Root TSL 

Version 2 and subsequent ones of TS 102 231 [i.10] make it possible to point from the TSL issued by one REM-PD 
Authority to the TSLs published by other REM-PD Authorities. Optionally one REM-PD Authority may implement a 
mechanism different from the TSL to point to other REM-PDs TSLs, but the at least the TrST based mechanism to go 
back to the relevant TSL-based information or to any equivalent information shall be implemented to ensure 
interoperability. 

If a REM-PD authority makes use of TSL to point to other TSLs issued by different Authorities, each TSL issuer shall 
implement what is specified in clause 7.1 where, to ensure interoperability, in provisions a), b), d), the "should" 
keyword is to be changed in "shall". 

Additionally what is hereinafter specified also applies. 

In the case addressed by this clause, each REM-PD Authority, depending on the REM-PD rules, has the right to 
recognise a number of other REM-PDs and to specify their recognition status in the TSL it issues and maintains. 

Each TSL issuer shall collect in a reliable way the information, to be placed in its TSL, about the "external TSLs" 
whereabouts (i.e. URL) and digital identity (e.g. the signer's certificate) through which the related TSLs can be accessed 
and its integrity and authenticity can be verified. 

One TSL issuer may act in one of the following two ways: 

1) it may list the recognised external REM-PDs along with the "List of Trust Service Providers" detailed in 
clause 5.3.17 of the TS 102 231 [i.10]; 

2) it may implement a tuple of what can be called a "Base TSL", of type "Generic", and a "Bridge TSL", of Type 
"Schemes", (as defined in clause 5.3.3 "TSL type" of TS 102 231 [i.10]); 

3) the "Base TSL" would only list REM-MDs belonging to the REM-PD at issue and would point, by means of 
the field "Pointers to other TSLs" (TS 102 231 [i.10], clause 5.3.13), to the "Bridge TSL" that would list only 
external REM-PDs in its "List of Trust Service Providers" section. 

It is to be remarked that the pointed-to REM-PDs may or may not reciprocate the recognition. 

7.2.1 Interoperable REM-PDs TSL - No Root TSL: an example 

Figure 7 presents a possible usage of TSL for interoperable REM-PDs with no Root TSL. Different types of TSLs are 
represented, with their relationships, in detail: 

1) REM-PD 1 implements one "Base TSL - Bridge TSL" mechanism; its Base TSL points to the Bridge TSL that 
in turn points to the TSLs of the other domains recognised by the governing Authority; 

2) REM-PD 2 implements a TSL of Type "Generic" where REM-MDs internal to the REM-PD are listed along 
with the external REM-PDs recognised by the REM-PD 2 Authority; it can be noticed that in this example 
REM-PD 2 does not recognise REM-PD 1, while it recognises REM-PDs 3 and 4; 

3) REM-PD 3 implements a "Generic" TSL; it recognises REM-PDs 1 and 4, but not REM-PD 2; 

4) REM-PD 4 implements one "Base TSL - Bridge TSL" mechanism; its Bridge TSL points to the TSLs of 
REM-PDs 1 and 3, but not to that of REM-PD 2. 
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Figure 7 



7.3 Interoperable REM-PDs TSL - Root TSL 

What is specified in clause 7.1 applies. To ensure interoperability in provisions a), b), d), the "should" keyword is to be 
changed to "shall". 

Additionally what is hereinafter specified also applies. 

In this TSL implementation a Higher Authority assesses the abidance by the common rules only of the directly 
governed REM-PDs that will in turn be responsible to assess the abidance by the respective REM-PD rules of each 
REM-MD they govern. 

This higher Authority is responsible to issue and maintain a Root TSL, of Type "Schemes", where the "lower level" 
REM-PDs, that in turn issue their own TSLs, are listed as TSPs. In the Root TSL each TSL entry related to one of these 
"lower level" REM-PD points to the TSL issued by the relevant governing Authority as well as the digital identity 
(e.g. the signer's certificate) with which the related TSLs integrity and authenticity can be verified. Likewise, all subject 
TSLs point to the Root TSL. 

In this case this Higher Authority shall be responsible to collect in a reliable way the above mentioned information on 
the ""lower level TSLs" URL and digital identity. 
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7.3.1 Interoperable REM-PDs TSL - Root TSL: an example 

Figure 8 presents a possible usage of TSL for interoperable REM-PDs with Root TSL. 
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Figure 8 
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Annex A (informative): 

REM Events and Actions flows 



Figure A. 1 describes the sequence of actions performed by the involved entities (from the REM Sender up to the REM 
Recipient or to external entities, like regular e-mail server or printer server) and of the related events that lead to 
issuance and delivery of REM-MD Evidence. Event types are not indicated: they are detailed in clause 6.2. 

1) Actions - Every action, to each of which one row is dedicated, is indicated in the column of the entity that 
performs it. From each action, arrows point to the entities the same action is directed to or to the events 
described in the related REM-MD Evidence, as specified in clause 6.2. These events are represented with 



boxes having this appearance: 



Text A.1 



where the text 



2) Events - Events are represented with boxes having the following appearance: I 

describes the related event, as indicated in clause 6.2, and the small box inside refers to the event type as 
numbered in the same clause 6.2. Boxes related to successful events have a white background, those referring 
to unsuccessful ones have a background that prints in gray. 

3) Junctions, i.e. where one action may produce more than one event, or one event is followed by more other 
events that can occur alternatively, are represented with a circle O. Where applicable, black circles with white 
numbers inside indicate the sequence with which the events occur. 



4) The symbol 5Hs indicates the entity to which an REM-MD Evidence, consequent to one event, is delivered. 
Connections to this symbol are in dotted arrows. 

One REM-MD Message may refer to another REM-MD Message referring in turn to the final Original Message to be 
downloaded, therefore REM-MD Message Delivery (Action No 5) and REM Object download (Action No 6) can be 
iterated. 

NOTE: Due to space restrictions the terms defined in clause 3.1 are shortened also by removing terms like REM 
and REM-MD where necessary. 
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Figure A.1 : Actions sequence 
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Figure A.2 specifies the sequence of the events performed when REM Object flow from one end (namely the REM 
Sender) to another end that can be the REM Recipient or provider of ordinary e-mail services or of printing services. 



A - 1 ' Text 



where the text 



1) Events - Events are represented with boxes having the following appearance: 
describes the related event and the small box inside refers to the event number as in the following clauses. 
Boxes related to successful events have a white background. 

Boxes referring to unsuccessful ones have a background that prints in gray. 

The box related to a regular e-mail that is received by the REM Recipient's REM-MD has a hatched 
background. 

2) One REM-MD Message may refer to another REM-MD Message referring in turn to the final Original 
Message to be downloaded, therefore REM-MD Message Delivery (Event D.l) and REM Object download 
(Event E.4) can be iterated. 

3) Events related to servers external to the REM lie on a light gray background. 
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Figure A.2: REM Events flow 
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